Presence indication configuration methodology

ABSTRACT

A presence model is maintained for a messaging system to message among a plurality of computing device users. A permission is maintained for providing to a first computing device a presence indication for a user of a second computing device. Based on an indication of a user of the first computing device not being in a messaging list for the user of the second computing device, the permission is maintained to provide only a basic presence indication to the first computing device for the user of the second computing device. From the first computing device, a message is caused to be sent to the second computing device. Based on the maintained permission, the basic presence indication for the user of the second computing device is provided to the first computing device and a user interface element is provided via which the user of the first computing device can be added to a messaging list for the user of the second computing device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation and claims priority under 35 U.S.C.120 to U.S. patent application Ser. No. 12/209,859, filed Sep. 12, 2008entitled “PRESENCE INDICATION CONFIGURATION METHODOLOGY” to MehulSanghavi et al. This application is incorporated in its entirety byreference as if fully set forth herein.

BACKGROUND

Presence, in a networked enterprise setting, is a published indicationof a user's availability and/or willingness to communicate with otherusers, such as by instant messaging (IM). The indication may be “basic,”including only limited information about the user (“online” or“offline”), or the indication may be “extended,” including moreextensive information about the user, such as status and/or profileinformation.

In accordance with one basic presence model, one user (User A) cannotsee the presence indication for another user (User B) unless thefollowing condition is met:

-   -   User A adds User B to User A's messenger list; and    -   Either        -   User B approves (authorizes) User A to be on User B's            messenger list; or        -   User B approves (authorizes) User A to view User B's            presence without User A being added to User B's messenger            list.            Thus, once User B approves User A, each user can see the            online presence indication of the other user.

It can be difficult for a user to leverage existing contact informationto initiate contact with other users. This can be an impediment tobuilding a critical mass of users with which a particular user may IM.One proposed solution has included a user sending mass invitations toother users to add the user to the other users' messenger lists, butthis process can be cumbersome, redundant and chaotic.

SUMMARY

In accordance with an aspect, a method is provided to maintain apresence model for a messaging system to message among a plurality ofcomputing device users via a communication network. A permission ismaintained for providing to a first computing device a presenceindication for a user of a second computing device. Based on anindication of a user of the first computing device not being in amessaging list for the user of the second computing device, thepermission is maintained to provide a basic presence indication to thefirst computing device for the user of the second computing device andto not provide to the first computing device an enhanced presenceindication for the user of the second computing device.

From the first computing device, a message is caused to be sent to thesecond computing device. Based on the maintained permission, the basicpresence indication for the user of the second computing device isprovided to the first computing device. Additionally, a user interfaceelement is provided, to provide an indication to the messaging system ofwhether to add the user of the first computing device to a messaginglist for the user of the second computing device, so as to maintain thepermission to provide the enhanced presence indication to the firstcomputing device for the user of the second computing device.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a system diagram illustrating how the provision of presenceindications of users may be configured in accordance with an aspect.

FIGS. 2A-2D collectively show a storyboard diagram illustrating severalscenarios with respect to how a presence model may be configured toselectively present basic and enhanced presence indications.

FIG. 3 is a table illustrating an example of states with respect towhether a particular user is provided with the presence indication,basic or extended, of another user.

FIG. 4 is a simplified diagram of a network environment in whichspecific embodiments of the present invention may be implemented.

FIG. 5 is a flowchart illustrating an example process to, using theexample users of Sara and Aaron, determine whether Sara and Aaron areadded to each other's messaging lists.

FIG. 6 is a flowchart illustrates an example process to, still using theexample users of Sara and Aaron, determine what presence indication topresent to Aaron for Sara.

FIG. 7A is an example of a slider user interface, in which a privacysetting may be set anywhere from “private” to “public”, with otherintermediate settings. FIG. 7B is a table illustrating an example of thecontinuum of preset privacy settings.

DETAILED DESCRIPTION

The inventors have realized the desirability of allowing users morecontrol over how their presence indication may be presented to otherusers and, in particular, allowing for finer grained control withrespect to casual and intimate contact. In a broad aspect, a basicpresence indication for a particular user may be automatically providedto another user based on the other user causing a message to be sent tothe particular user, the basic presence indication for the particularuser being provided without explicit authorization being required by theparticular user. In addition, the particular user may control, via auser interface provided to the particular user based on the messagebeing sent from the other user to the particular user, whether the otheruser is allowed to be provided an enhanced presence indication for theparticular user.

Thus, for example, basic presence information can be provided to userswith whom the particular user may have only casual contact, without anyspecial configuration being required, whereas enhanced presenceinformation may be provided to users with whom the particular user hasor desires to have more intimate contact. Furthermore, the level ofpresence information allowed to be provided need not be decided by theparticular user in advance of the contact. In addition, the user may beprovided the ability to control a global “default” presence indication,which may provide more less information than the basic presenceinformation, and which may be overridden by more a detailedconfiguration based on user's messenger list (e.g., the messenger listmay be configured to allow an enhanced presence indication to beprovided to a particular other user or to completely block a presenceindication from being provided to a particular other user).

FIG. 1 schematically illustrates an aspect of the invention, in which aplurality of users (User A 102 a, User B 102 b, . . . , User X 102 xcollectively, indicated by reference numeral 102) may communicate over anetwork using a communication methodology such as instant messaging(IM). While some of the users may be on the same IM network, some of theusers may be on different IM networks, such that inter-networkcommunication is required to accomplish IM communication between suchusers. In some instances, the networks may operate according todifferent IM protocols, such as by accommodating for the dissimilarprotocols inside the IM client application or by accommodating for thedissimilar protocols inside an IM server application.

Referring still to FIG. 1, the messaging network or networks (such as anIM network or networks) are denoted by the reference numeral 104.Typically, the IM networks 104 operate using a protocol operating overone or more public or quasi-public networks. Furthermore, an IM“presence model” 106 governs the mechanism and rules by which presenceindications are shared among the users 102. The presence model istypically implemented by functionality on any one or more of clientdevices employed by the users 102 and/or any one or more of serversemployed by one or more IM service providers.

Furthermore, FIG. 1 illustrates a scenario in which the user A 102 ainitiates communication to user B 102 b via the messaging networks 104,as represented by arrow 108(1). This may include, for example, user A102 a interacting with a client computing device to cause an instantmessage to be sent to user B 102 b. Furthermore, user A 102 a is not inthe messenger list for user B 102 b, nor is user A 102 a on a block listfor user B 102 b. As a result of the message being sent, the presencemodel 106 operates (108(2)) to cause a basic presence indication forUser B 102 b to be provided to User A 102 a. Thus, user A 102 a knew theIM identification for user B 102 b and, thus, is able to send a messageto user B 102 b and get a basic presence indication for user B 102 b.Furthermore, in accordance with some examples, as a result of theinstant message being sent to User B 102 b, a presence indication (basicor enhanced) for User A 102 a may be provided to User B 102 b.

In addition, a user interface element is caused (108(3)) to be providedto User B 102 b, regarding whether the presence model 106 should allowan enhanced presence indication for User B 102 b to be provided to UserA 102 a. In addition, the user interface element may also be regardingwhether the presence model should allow even the basic presenceindication for User B 102 b to be provided to User A 102 a.

Thus, User B 102 b may, via the user interface element, approve (108(4))the provision of the enhanced presence indication for User B 102 b toUser A 102 a or block the provision of any presence indication for UserB 102 b to User A 102 a. In this case, user B 102 b approves adding userA 102 a to the messenger list for user B 102 b, and the enhancedpresence indication for User B 102 b is allowed to be provided (108(5))to User A.

In some examples, User B 102 b may neither approve the provision of theenhanced presence indication nor block the provision of any presenceindication. In such an example, a default action may be taken, such ascontinuing to allow the basic presence indication for User B 102 b to beprovided to User A 102 a. Furthermore, if a presence indication for UserA 102 a was provided to User B 102 b, this may aid User B 102 b indetermining what action to take with respect to allowing a presenceindication for User B 102 b to be provided to User A 102 a by, forexample, providing additional information helpful for user B 102 b tomake a determination.

It can thus be seen that, in accordance with one broad aspect, a usermay precisely control access to her presence information, based on aninformed decision prompted by an attempt by another user to send amessage to that user. In addition, the attempt by the other user to sendthe message to that user may result in allowing enhanced presenceinformation for the other user to be provided to that user, so as tofurther inform that user's decision.

FIGS. 2A-2D collectively show a storyboard flowchart illustrating, ingreater detail, a scenario providing an example of this presence modelaccess methodology. The story involves two users—Sara and Aaron. Atframe 202, Aaron desires to converse with Sara, but Aaron doesn't knowwhether Sara is online since, at this point, Aaron has not been providedaccess to Sara's presence information. At frame 204, Aaron decides totype Sara's name into the contacts search bar. In the example, Sara isin Aaron's address book, so Sara's messaging ID is autocompleted. Atframe 206, Aaron inputs a message to Sara and presses the “send” button.

In the example shown in the FIGS. 2A-2D storyboard, at frame 208,because Aaron identified Sara and sent Sara a message, in the presencemodel, Sara is implicitly added to the list of users for whom Aaron canbe provided a presence indication—in this case, a basic presenceindication. At frame 210, Sara receives a notification of the incominginstant message from Aaron. Frame 212 is an indication of Sara'squandary, whether or not to communicate with Aaron.

Frames 214 to 230 illustrate an example in which Sara decides tocommunicate with Aaron. At frame 214, Sara decides to communicate withAaron. At 216, Sara clicks on the IM tab for Aaron's message, whichindicates that the message from Aaron is new and unread. At 218, Saraviews Aaron's presence indication (which, in the FIGS. 2A-2D storyboardexample, is an enhanced presence indication such that more than thebasic “online”/“offline” indication is provided).

At 220, a user interface element is provided via which Sara may addAaron to a messenger list associated with Sara, such that Aaron isprovided an enhanced presence indication for Sara. In addition, Sara mayalso utilize the user interface element to block Aaron from receivingeven a basic presence indication for Sara, by adding Aaron to Sara'sblock list. However, at 222, Sara converses with Aaron, all the whilewithout having utilized the user interface element discussed withrespect to 220. In this example, Aaron continues to be provided thebasic presence indication for Sara, as a default. At 224, Sara closesthe IM window. At 226, a dialog box user interface element is displayedto Sara, inquiring as to whether Aaron should be added to Sara'smessenger list. At 228, Sara adds Aaron to Sara's messenger list, andSara is provided Aaron's enhanced presence indication. At 230, due toSara's action to add Aaron to her messenger list, Aaron continues to beprovided Sara's enhanced presence indication. It can thus be seen thatthe bi-directional relationship (in which both Aaron and Sara get accessto each other's enhanced presence indication) is not establishedautomatically but, rather, depends on Sara and how quickly Sara decidesto reciprocate Aaron's request (in this example, as Aaron's request isevidenced by Aaron sending the message to Sara).

Frames 232 to 240 illustrate a scenario in which Sara decides to notallow Aaron to be presented Sara's presence indication at all. At frame232, Sara determines that she doesn't know Aaron. At frame 234, Sara iscontemplating blocking Aaron permanently from being provided Sara'spresence indication. However, at frame 236, Sara decides to just closethe tab indicating Aaron's message to Sara. At 238, Sara is presentedwith a dialog box user interface item via which Sara may put Aaron onSara's block list, to block Aaron from being provided Sara's presenceindication and, furthermore, to block future messages from Aaron. At240, from Aaron's point of view, Sara has gone offline, since Aaron isblocked from being provided Sara's presence indication. (It should benoted that, even if Aaron is on Sara's block list, Aaron may still haveaccess to Sara's online presence indication which, as discussed withreference to an example below, may provide Sara's online presence as adefault if Aaron requests the online presence but is not identified tothe IM presence model as Aaron—i.e., for example, is not “logged in.”)

It can thus be seen that a user can control, via her messenger list andblock list, what other users will be provided her basic and/or enhancedpresence indication, while there is a default state that users not inthe messenger list or block list will be provided the basic presenceindication as a result of identifying the user (e.g., by sending theuser a message). FIG. 3 is a table illustrating an example correspondingto the FIGS. 2A-2D storyboard example, of states with respect to whethera particular user (in the example, Aaron) is provided with the presenceindication, basic or extended, of another user (in the example, Sara).Row 302 represents the state of Aaron being provided with a basicpresence indication for Sara, and row 304 represents the state of Aaronbeing provided with an extended presence indication for Sara.Furthermore, column 306 represents the conditions under which the statesrepresented by the rows exist, and column 308 represents what stateotherwise exits, in the absence of the column 306 conditions.

Turning now to FIG. 3 and specifically to column 306, it can be seenthat, in accordance with the example, in order for Aaron to be providedSara's basic presence indication, there is nothing that Aaron must dobeyond specifically identifying Sara, such as by sending a message toSara. On the other hand, Aaron must not be in Sara's block list. Thus,from column 308, in accordance with the example, it can be seen whatoccurs if the conditions in column 306 are not met. For example, ifAaron is in Sara's block list, then the presence indication provided toAaron for Sara will always indicate that Sara is “offline.” Furthermore,if Aaron is not in Sara's block list, but Aaron also is not in Sara'smessenger list, then the presence indication provided to Aaron for Sarawill be a basic presence indication.

It should be noted that the previous examples are just that—examples—andother examples are possible. For example, providing or blocking apresence indication is not limited to what is specifically described.For example, blocking Sara's presence indication from being provided toAaron may include completely blocking the presence indication (and, forexample, indicating that the presence information is being blocked orotherwise providing a “null” indication) or, in some examples, it mayinclude allowing the provision of a presence indication to Aaron that isessentially meaningless, such as always providing an indication thatSara is offline, whether or not that presence indication is trulyindicative of Sara's presence status.

As another example, the presence or absence of Aaron on a white list orblack list associated with Sara may be overridden by othercircumstances, such as global profiles associated with the presencemodel. As one example, Sara's IM system may be administrativelyconfigured to not allow presence indications to be provided to users ofcertain domains, or to only allow presence indications to be provided tousers of certain domains. As another example, Sara may have configuredher profile in a “do not disturb” mode to globally present an offlinepresence indication, even though Sara is not offline.

In accordance with an additional aspect, a global online presenceindicator may be enhanced such that an individual user's messagingand/or block list is consulted, thus minimizing or avoiding inconsistentpresence indications. Conventionally, global online presence indicationsare provided without consultation to a user's messenger and/or blocklist. In accordance with the additional aspect, then, the particularuser can configure the global online presence indicator to provide adefault presence indication, which may be overridden based on theparticular user's messenger and/or block list, without regard for otherusers' messenger lists. That is, this enforces the notion that the onlyusers who can see the particular user's enhanced presence indication areusers who are on the particular user's messaging list, without regardfor whether, at some point, the particular user had given permission forthe other user's to put the particular user on their messaging lists.

Put another way, as an example, the user can have the ability to set aglobal “do not show me as online” preference that will override theability to see that user's basic presence by all users not on thatuser's messaging list. This may be seen as akin, for example, to notpublishing a user's phone number in the phone book—but anyone who iscalled by that user can see the user's number/name via caller ID.

As another example, Sara may have configured her profile to allowparticular information to only be provided to particular denoted users,such as very personal information that Sara desires is not to be madegenerally available even as part of her “normal” enhanced profile,except perhaps to close friends or family. Such configuration may bemade, for example, using user interface elements associated with Sara'smessenger list.

A useful result of the scenarios discussed above includes, for example,that a user can be prompted to decide “on the fly” if she wishes tocommunicate with a particular other user, as the particular other userattempts to communicate with that user. Furthermore, that “on the fly”decision may include treating the particular other user as a mere casualcontact such as, by allowing only basic presence information to beprovided to the particular other user. In addition, by prompting a userto build up her messenger list “on the fly,” this can overcome whatmight otherwise be an impediment to using instant messaging, which isthat generally one would have to populate a messenger list with contactinformation for other users prior to being able to carry on instantmessaging communication with those users.

We now refer to FIG. 5, which is a flowchart illustrating an exampleprocess to, using the example users above of Sara and Aaron, determinewhether Sara and Aaron are added to each other's messaging lists (which,as discussed above, a presence model uses to control how and whatpresence indications are provided). The top portion 502 indicatesprocessing with respect to Aaron (a message sender), whereas the bottomportion 552 indicates processing with respect to Sara (a messagerecipient).

Starting with the top portion 502, processing begins at 504. At 506,there are two diverging paths. At 508, Aaron clicks an “add” button on auser interface presented to Aaron and provides Sara's messenger ID. Onthe other path, at 510, Aaron sends Sara a message (such as an instantmessage). At 516, Aaron adds Sara to Aaron's messenger list. Access toSara's online presence indication (OPI) is, at this point, according toSara's global preferences, since Aaron is neither in Sara's messaginglist nor in Sara's block list. At 518, if it was not already provided, anew messaging window is presented to Aaron with a message addressed toSara. At 520, processing ends. Continuing now on the other path, from510, at 512, it is determined if Aaron decides to add Sara to Aaron'smessenger list. If not, processing ends at 514. If so, then processingcontinues at 516, where access only to Sara's OPI is provided.

We now refer to the lower portion 552 of FIG. 5, which indicatesprocessing with respect to Sara. At 554, it is determined if Sara hasAaron in Sara's block list. If not, then Sara receives a new messagealert at 556. At 558, it is determined if Aaron is in Sara's messengerlist. If Aaron is already in Sara's messenger list, then add processingwith respect to Sara ends 560. Also, if at 554, it was determined thatSara has Aaron in Sara's block list, then Aaron's message is dropped 562(e.g., with neither Aaron or Sara being notified of such) and processingends 560.

If, at 558, it is determined that Sara does not have Aaron in Sara'smessenger list, then three alternatives 564 are possible. At 566, Saradecides to add Aaron to Sara's messenger list. Access to Aaron's OPIrelies upon Aaron's preferences. At 568, Sara decides to block Aaron.Aaron is added to Sara's block list, and Aaron cannot even see Sara'sOPI, since the block list overrides the OPI. At 570, Sara does nothingwith respect to adding Aaron, so Aaron is neither on Sara's messengerlist nor on Sara's block list, and processing ends at 576.

Having described the “add flow” (processing to add a user to a messengerlist or block list), we now describe with reference. In this case, FIG.6 illustrates how it may be determined what presence indication topresent to Aaron for Sara. The top portion 602 refers to processing withrespect to Aaron (a message sender), whereas the bottom portion 652indicates processing with respect to Sara (a message recipient).Processing begins at 604.

At 606, an IM Window/Profile with Sara is opened. On Sara's side (seebottom portion 652 of FIG. 6), if Sara has Aaron in Sara's block list,then Sara's presence is presented to Aaron as offline. If, at 654, Saradoes not have Aaron in Sara's block list then, if Sara has Aaron inSara's messenger list (656) then, at 658, Aaron sees Sara's enhancedpresence indication, such as including status message, if Sara hascreated a status message. Otherwise, if at 654, Sara does not have Aaronin Sara's block list and Sara does not have Aaron in Sara's messengerlist, then, at 660, Aaron only sees Sara as “available” or “offline.”

On the other hand, if Sara does not have Aaron in Sara's block list(654) and, at 662, Sara is offline to Aaron (either because Sara istruly offline, is invisible to everyone, or is selectively invisible toAaron), then Aaron sees Sara as offline (656). Otherwise, Aaron seesSara as online 664.

Having described examples of add flow and presence flow, we now describean example in which a user may control her online presence indication(OPI), and related messaging privacy settings, globally. Furthermore,the example provides that the user may control her OPI using a continuumof preset privacy settings, beyond a mere binary on/off setting for theonline presence indication. In FIG. 7 a, an example is shown of a slideruser interface 702, in which a privacy setting may be set anywhere from“private” 704 to “public” 706, with other intermediate settings.

FIG. 7B is a table illustrating an example of the continuum of presetprivacy settings. Column 754 (corresponding to the setting 704 in FIG.7A) has preset privacy settings for “status,” “IM's,” “add requests” and“sharing” that correspond to what is deemed to be the most private ofsettings. On the other hand, column 756 (corresponding to the setting706 in FIG. 7A) has preset privacy settings that correspond to what isdeemed to be the most public of settings. Columns 758,760 and 762 havepreset privacy settings that are progressively more public.

For example, with the settings of column 754, in general, no one willsee when the user is online, and the user will not receive messages fromusers outside of those explicitly listed on the user's messenger list.For column 758, only users explicitly added to a user's messenger listwill see when the user is online. In addition, the user will be alertedwhen users not on the user's messenger list attempt to see when the useris online. The middle column 760, is a “middle ground,” such that userscan see when the user is online, but the other users will not see theuser's enhanced presence indication (e.g., including a status messagefor the user). That is, only a basic presence indication is provided tousers not in that user's messenger list.

The column 762 is such that, in addition to those listed in the user'smessenger list, users listed in those users' messenger lists (“friendsof friends”) can also see the user's enhanced presence indication.Finally, as mentioned above, the column 756 includes preset privacysettings that are the most public, such that anyone can see when theuser is online and, in addition, can see the user's enhanced presenceindication, including a status message.

Embodiments of the present invention may be employed to configurepresence indications in a wide variety of computing contexts. Forexample, as illustrated in FIG. 4, implementations are contemplated inwhich users may interact with a diverse network environment via any typeof computer (e.g., desktop, laptop, tablet, etc.) 402, media computingplatforms 403 (e.g., cable and satellite set top boxes and digital videorecorders), handheld computing devices (e.g., PDAs) 404, cell phones406, or any other type of computing or communication platform.

According to various embodiments, applications may be executed locally,remotely or a combination of both. The remote aspect is illustrated inFIG. 4 by server 408 and data store 410 which, as will be understood,may correspond to multiple distributed devices and data stores.

The various aspects of the invention may also be practiced in a widevariety of network environments (represented by network 412) including,for example, TCP/IP-based networks, telecommunications networks,wireless networks, etc. In addition, the computer program instructionswith which embodiments of the invention are implemented may be stored inany type of tangible computer-readable media, and may be executedaccording to a variety of computing models including, for example, on astandalone computing device, or according to a distributed computingmodel in which various of the functionalities described herein may beeffected or employed at different locations.

1. A method of maintaining a permission model for a messaging system tomessage among a plurality of computing device users via a communicationnetwork, wherein the permission model governs what level of presenceinformation may be provided to the computing device users regardingother computing device users, the method comprising: receiving a requestfrom a first user, of a first computing device, to subscribe to presenceinformation of a second user, of a second computing device, and, basedthereon, allowing the first user to receive a basic level of presenceinformation of the second user; based on receiving the request from thefirst user, querying the second user as to whether to allow the firstuser to receive an enhanced level of presence information of the seconduser; and based on a response to the query, from the second user,configuring the permission model to govern what level of presenceinformation of the second user is allowed to be provided to the firstuser.
 2. A method of maintaining a presence model for a messaging systemto message among a plurality of computing device users via acommunication network, comprising: maintaining a permission forproviding to a first computing device a presence indication for a userof a second computing device; based on an indication of a user of thefirst computing device not being in a messaging list for the user of thesecond computing device, maintaining the permission to provide a basicpresence indication to the first computing device for the user of thesecond computing device and to not provide to the first computing devicean enhanced presence indication for the user of the second computingdevice; from the first computing device, causing a message to be sent tothe second computing device and, based on the maintained permission,providing the basic presence indication for the user of the secondcomputing device to the first computing device; and providing a userinterface element at the second computing device to provide anindication to the messaging system of whether to add the user of thefirst computing device to a messaging list for the user of the secondcomputing device, so as to maintain the permission to provide theenhanced presence indication to the first computing device for the userof the second computing device.
 3. The method of claim 2, wherein: thebasic presence indication includes an indication of whether the user ofthe second computing device is online to receive messages from the firstcomputing device.
 4. The method of claim 3, wherein: the enhancedpresence indication includes all of the information in the basicpresence indication and, additionally, includes information about theuser of the second computing device beyond merely whether the user ofthe second computing device is online to receive messages from the firstcomputing device.
 5. The method of claim 2, further comprising: based onnot receiving an indication to the messaging system of whether to addthe user of the first computing device to a messaging list for the userof the second computing device, maintaining the permission to providethe basic presence indication to the first computing device for the userof the second computing device.
 6. The method of claim 2, wherein: theuser interface element is additionally to provide an indication to themessaging system of whether to add the user of the first computingdevice to a block list for the user of the second computing device, soas to maintain the permission to provide no presence indication to thefirst computing device for the user of the second computing device. 7.The method of claim 2, wherein: maintaining the permission furtherincludes maintaining a global default presence indication for the seconduser; and wherein the method further comprises responding to a globalpresence indication request made by the user of the first computingdevice for the presence indication of the second user, includingdetermining if the user of the first computing device is an identifieduser; if the user of the first computing device is determined to not bean identified user, providing the global default permission as therequested global presence indication; and otherwise, if the user of thefirst computing device is in the messaging list associated with thesecond user, providing the user of the first computing device with theenhanced presence indication for the user of the second computing deviceas the requested global presence indication.